17 Bit Software 3: The Continuation/17-Bit_The_Continuation_Disc.iso/amigan/amigan 16/chatty/chatty.doc

Text File | 1994-01-27 | 9KB | 144 lines

                                          This issue, we continue our quest for
     From Issue 2, Volume III of          programming methods universally suited
     the Amigan Apprentice &              for all Amigas, domestic and foreign,
     Journeyman--John Toebes's            NTSC or PAL--and for whatever language
     column, "Oh Say Can you C".          the user may speak (so long as it is
                                          written from left to right in roman
                                          characters). To illustrate how simple
it is to write conformable code, I present the program listed on a separate in-
sert sheet, CHATTY.C. It takes the form of a demo window for Workbench. It shows
several features required in the design of a good program for an Amiga.

1) It understands MOREROWS (and similar programs) and interlace.

2) Its messages can be configured as the user specifies, without recompiling the
   program.

3) It multi-tasks well. Even though it prints random text, it does not hog the
   CPU in a busy wait.

4) When deactivated, it goes to sleep.

 Let's deal first with MOREROWS and similar programs. Last issue, we saw that
information about the desired screen size is stored in GFXBASE. In our program,
we take this information and combine it with the interlace field data stored in
Preferences to calculate the Width and Height fields of our new window. This is
much better than determining whether the machine is NTSC or PAL and adding the
MOREROWS values ourselves (we can work on any default screen, no matter how big
or small). When we open a window on the Workbench screen, however, we must re-
spect the interlace bit and double window height accordingly.

 Changing Text: The most important part of this example is the method we use to
change the text we display without having to recompile the program.  We do this
by storing all message strings in the .info file that is asssociated with the
program file. Last issue, I wrote that we could store such strings in a separate
file. Is there a more appropriate place to store them than the .info file, which
is always copied by Workbench? Neither programmer nor user ever must worry about
the string file being always present and available.

  To see how strings are stored, simply click on any tool icon (the CLI one is a
good one) and select the INFO option from the menu of Workbench, which will then
display a window full of information about the CLI tool. Near the bottom of the
window will be a string gadget labelled "tool types," with an up-down arrow on
the left and an ADD/DEL gadget on the right. The arrows let you scroll through
the tools; ADD/DEL enables you to add and delete tool types.

  The basic syntax for a tool is much like a BASIC assignment statement (as at
the left, below). In this way, we can associate a string with any name. In Work-
                  bench is a routine, FindToolType, which will search this list
tool = string     of tool types and return the string associated with a given
                  name.

  In this way, we can specify configuration parameters for a program, which can
access those parameters by name. We can use this function to tailor a program--
by having the program draw both messages and text strings from the tool types.
All who use the program can revise the text of its messages with the INFO window
of Workbench. There, they can change--to heart's content--whatever needs change.
For a programmer, this means that a German language edition of a program demands
only that the .info file be done with German messages.

 In Chatty.c, I use strings for only three things (see below). Although storing
                                             strings in the tool types array has
1) A title for the window we open.           the advantage of configurability,
                                             it has the disadvantage that the
2) An error message if we can't open it.     .info file must always be present
                                             and that it have the right data in
3) Strings printed randomly in the window.   it. In Chatty.c, I have a default
                                             title and message in English, plus
a strings which is printed at random locations in varying colors. In the tool
types array in the .info file we might have the material at left, below:

TITLE=whatever title you want                To make the demo short and easy to
OPENFAIL=text when the window won't open     write, I don't use 26 strings. In-
STRINGA=first text string                    stead, the seven strings (A - G) in
...more strings                              the .info file are printed at ran-
STRINGZ=last text string [total, 26]         dom locations on the window. Were
                                             all the strings used as error mes-
sages or prompts in a working program, we'd have to pay more attention to their
content and location.

 We access the strings with three simple steps:

   1) Open icon.library and store the base in IconBase.

   2) Locate the .info file and the directory it is stored in. We have two situ-
ations to consider (always remember this!):

      a) In CLI, the program name is in argv[0]; the current directory is stored
in the process structure.

      b) On Workbench, as we noted in past columns, Workbench passes us a start-
up message that indicates our arguments and where they are located.

      Based on this information, we simply ask Workbench to get us the disk ob-
ject (icon information) for our program.  In it is the tool types array pointer
that we use.  The routine FindTools() gets this information for us from the di-
rectory and name.

   3) For each string we are interested in, we call FindToolType() to search the
tool types array. To make this easy to use, I've defined the routine getstr(),
which acts like FindToolType() except that it takes a default string to return
if none is found in the tool types array. In this way, we always have a string.
When none is supplied, we use our default (sent as an argument); otherwise, we
use what the user wants. The employment of getstr() is illustrated in the defin-
ition of the macro M_CANTOPEN, below. In our code we do a puts(M_CANTOPEN), and
it always works:

  #define M_CANTOPEN (getstr(toolptr, "OPENFAIL", "Can't Open the window"))

 Chatty.c uses few strings; in a more complex program, you'd want to define many
names for the strings.  Nothing is wrong with numbering the messages (M1 through
M99--or however many messages you need). Once you set up a method to identify a
message, it's easy to extend it for all messages (even for titles and menus).

   For this demo, I stuffed the strings into the .info file from the INFO menu
of Workbench. This would be tedious indeed if a program required several hundred
messages and was issued in French, German, English and Spanish. We need a small
program that will swiftly insert a list of messages into an .info file.

  We can take this one step further by allowing the user to enter configuration
options, such as default window sizes and gadget locations. Do we face a serious
limit on total string space in a a tool types array? The limit is 32K; it should
not be a problem for most programs.

 Busy or Waiting? In a demo such as Chatty, many of us code an infinite loop and
in it check for a message each pass through the loop. If a message isn't found,
the loop continues. Although such loops are a friendly way to multi-task, they
often perform operations too often or waste CPU cycles while they wait for some-
thing to happen.

  One way around this is to use the timer (see the source code for PopCLI and
MemWatch). The method is simple; you can suspend operation for a fixed period
and let the system wake you up. Yet, Intuition provides a much simpler mechanism
in the INTUITICKS IDCMP flag.  When you enable this, Intuition will send you a
message (about 30 times a second or so) so long as your window is active. If you
base your work on messages received, you regulate how much CPU time is consumed.
More importantly, if your window is deactivated, the messages stop; the program
effectively goes to sleep until a user again makes it active. This is the ulti-
mate in CPU sharing for an application that deals only with a user and does lit-
tle or no computation in the background.

  The INTUITICKS mechanism is not appropriate for every application, but if you
do have a free-running loop around a getmsg call, you may as well take advantage
of it to help regulate the amount of work.